Reviewing files that changed from the base of the PR and between 438da05 and 3671911.

• tests/__snapshots__/search.test.ts.snap is excluded by !**/*.snap

• .code-samples.meilisearch.yaml (15 hunks)
• README.md (6 hunks)
• eslint.config.js (1 hunks)
• playgrounds/javascript/src/meilisearch.ts (2 hunks)
• src/http-requests.ts (1 hunks)
• src/indexes.ts (3 hunks)
• src/meilisearch.ts (3 hunks)
• src/types/experimental-features.ts (1 hunks)
• src/types/index.ts (1 hunks)
• src/types/network.ts (1 hunks)
• src/types/search-parameters.ts (1 hunks)
• src/types/search-response.ts (1 hunks)
• src/types/shared.ts (2 hunks)
• src/types/token.ts (1 hunks)
• src/types/types.ts (7 hunks)
• src/utils.ts (1 hunks)
• tests/client.test.ts (1 hunks)
• tests/embedders.test.ts (0 hunks)
• tests/env/node/getting_started.cjs (1 hunks)
• tests/env/node/search_example.cjs (1 hunks)
• tests/env/typescript-node/src/index.ts (1 hunks)
• tests/facet_search.test.ts (0 hunks)
• tests/get_search.test.ts (0 hunks)
• tests/search.test.ts (1 hunks)
• tests/token.test.ts (2 hunks)
• tests/typed_search.test.ts (0 hunks)
• tests/utils/meilisearch-test-utils.ts (4 hunks)
• tests/utils/search.ts (1 hunks)
• tests/utils/test-data/films.ts (1 hunks)

• tests/get_search.test.ts
• tests/typed_search.test.ts
• tests/embedders.test.ts
• tests/facet_search.test.ts

tests/env/node/search_example.cjs (1)

27-29: Updated search method call signature correctly implemented

The search method call has been updated to use the new unified signature that accepts a single options object with the query string under the q key, aligning with the API changes mentioned in the PR objectives.

eslint.config.js (1)

44-49: Good addition of test assertion verification

Adding the vitest/expect-expect rule ensures all test files include at least one assertion call, which prevents false-positive tests that don't actually verify anything. This is a good practice for maintaining test quality.

src/http-requests.ts (1)

25-25:

✅ Verification successful

Simplified URL parameter handling

The parameter handling has been simplified by removing special Date object processing and using a more straightforward string conversion approach. This reduces code complexity while maintaining functionality.

---

🏁 Script executed:

#!/bin/bash
# Check if Date objects were handled elsewhere in the codebase

# Look for Date handling in parameter processing or serialization
rg -A 2 -B 2 "instanceof Date" --type ts

Length of output: 42

---

🏁 Script executed:

#!/bin/bash
# Locate the http-requests.ts file
HTTP_FILE=$(fd http-requests.ts)
echo "Inspecting: $HTTP_FILE"

# Display the first 100 lines to review parameter handling context
sed -n '1,100p' "$HTTP_FILE"

# Search within the file for any Date-specific logic
rg -n "Date" "$HTTP_FILE"

Length of output: 3276

---

🏁 Script executed:

#!/bin/bash
# Locate the type definition file for URLSearchParamsRecord
TYPE_FILE=$(fd --full-path "src/types/index.js")
echo "Inspecting: $TYPE_FILE"

# Show the definition of URLSearchParamsRecord
rg -n "URLSearchParamsRecord" -C 5 "$TYPE_FILE"

Length of output: 163

---

🏁 Script executed:

#!/bin/bash
# Find the TypeScript file defining URLSearchParamsRecord
FILE=$(rg -l "URLSearchParamsRecord" --type ts)
echo "Definition file: $FILE"

# Show the URLSearchParamsRecord type declaration
rg -n "URLSearchParamsRecord" -C 5 "$FILE"

Length of output: 369

---

🏁 Script executed:

#!/bin/bash
# Properly iterate over files containing the type and show its declaration
FILES=$(rg -l "URLSearchParamsRecord" --type ts)
for file in $FILES; do
  echo "---- $file ----"
  rg -n "URLSearchParamsRecord" -C 5 "$file"
done

Length of output: 1822

---

No Date-specific logic found; Date handling removal is safe

I searched the entire codebase and did not find any instanceof Date checks or other Date-specific serialization elsewhere, and the URLSearchParamsRecord type only permits primitives (string, number, boolean, etc.), so dropping the special Date branch has no unintended impact.

– No other Date handling detected in src/http-requests.ts or related files
– The simplified String(val) conversion covers all permitted param types

tests/token.test.ts (2)

335-336: Updated search method signature for token validation test

The search method call has been updated to use the new unified signature with a q parameter, maintaining the test's ability to verify that searching with invalid token permissions correctly triggers an API key error.

---

353-354: Updated search method signature for token validation test

The search method call has been updated to use the new unified signature with a q parameter, maintaining the test's ability to verify that searching with incorrect index permissions correctly triggers an API key error.

src/types/token.ts (3)

1-1: Well-structured type import update

The import has been correctly changed from Filter to SearchQuery to align with the renamed types mentioned in the PR objectives. This ensures consistency with the new type system.

---

4-4: Good use of type utility for better type safety

Using Pick<SearchQuery, "filter"> to extract only the filter property from the larger SearchQuery type is a good practice. It ensures type safety while keeping the interface minimal.

---

11-11: Improved documentation reference

Simplifying the reference to the core implementation with a direct mention of meilisearch_auth::SearchRules instead of a GitHub URL makes the documentation more maintainable and less prone to becoming outdated.

tests/env/node/getting_started.cjs (3)

30-30: Updated search method signature as per PR changes

The search method call has been correctly updated to use the new signature with a single parameter object containing the query string under the q property.

---

32-36: Proper implementation of filtered search with new signature

The filtered search now correctly uses the new unified parameter object pattern, properly including both the query string and filter parameters in a single object.

---

38-42: Faceted search correctly updated to new API format

This faceted search correctly implements the new parameter structure, using an object with q, filter (as an array), and facets properties. This is consistent with the API signature changes described in the PR objectives.

tests/client.test.ts (2)

41-45: Added test setup for experimental network feature

Good addition of a beforeAll hook to enable the experimental network feature. This supports testing the new network-related functionality mentioned in the PR objectives.

---

47-51: Proper cleanup of experimental settings after tests

The afterAll hook correctly disables the experimental feature before cleaning up indexes, ensuring tests don't leave side effects that could impact other test suites.

src/types/index.ts (1)

1-6: Good organization of expanded type exports

These new exports provide a well-structured approach to exposing the refactored and new TypeScript types mentioned in the PR objectives. This ensures that all the new search-related types, experimental features, and network types are properly accessible throughout the codebase.

src/utils.ts (2)

19-35: Nice utility function implementation!

This generic utility function for stringifying specific keys in a record is well-typed and elegantly implemented. The type parameters ensure type safety while the mapped return type accurately preserves the original types for untouched keys and correctly annotates stringified values as strings.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 24-25: src/utils.ts#L24-L25
Added lines #L24 - L25 were not covered by tests

---

37-42: Export organization is clean and clear

The exports are neatly organized, making it clear what utilities are available from this module.

src/types/network.ts (2)

1-9: Well-documented Remote type

The type definition includes helpful documentation links to the official API reference and corresponding Rust implementation. The structure with an optional API key accommodates different authentication scenarios.

---

11-19: Network type looks good

The Network type is well-structured to model both self-reference and remote connections. The documentation is clear and links to the appropriate references.

playgrounds/javascript/src/meilisearch.ts (3)

1-4: Import updated correctly to include the new type

The import has been properly updated to include the SearchQueryWithOffsetLimit type, which aligns with the PR objective to refactor the search method signatures.

---

42-47: Search method signature updated appropriately

The implementation now correctly uses the new search method signature with a single parameter object containing q and other properties, as described in the PR objectives.

---

49-51: Console output format updated to reflect parameter changes

The string template has been appropriately updated to display the new search parameter object structure.

.code-samples.meilisearch.yaml (7)

17-20: Search parameter format updated correctly

The date guide filter example has been updated to use the new search method signature with a single object parameter containing q and filter properties.

---

24-27: Sort example properly converted

The date guide sort example now correctly uses the object format with q and sort properties.

---

83-85: Basic search examples correctly updated

Both the POST and GET search examples have been properly updated to use the new object format with the q property.

---

307-310: Filter examples consistently updated

All filter examples now correctly use the object parameter format with q and filter properties, maintaining consistency across the codebase.

Also applies to: 312-315, 317-320

---

462-462: Getting started example correctly updated

The getting started search example correctly demonstrates the new API format.

---

771-774: Advanced parameters example updated properly

The example for showRankingScoreDetails has been correctly updated to the new parameter format.

---

789-795: Hybrid search example is consistent with new format

The hybrid search example follows the new parameter structure correctly, maintaining consistency with other examples.

src/types/experimental-features.ts (1)

1-14: Well-structured type definition for experimental features.

The RuntimeTogglableFeatures type is well-documented with references to API docs and backend structure. The optional boolean/null properties provide flexibility for feature toggling.

tests/env/typescript-node/src/index.ts (4)

27-27: Proper use of generic type parameter.

Good use of generics to type the index with the Movie interface, providing type safety for search operations and hits processing.

---

34-36: Search signature change correctly implemented.

The code correctly uses the new search API that accepts a single parameter object with q property for the query string, aligning with the PR objectives to unify search method signatures.

---

41-43: Correctly using updated search method.

The search implementation follows the new pattern documented in the PR objectives, using a single parameter object instead of separate query and options parameters.

---

45-53: Proper type handling for hits.

The code correctly handles optional properties in search hits using the nullable chain operator, improving type safety. This is a good practice when working with search results.

tests/utils/meilisearch-test-utils.ts (5)

3-3: Good addition of Task type import.

Importing the Task type provides better type safety for the new isTaskSuccessful helper function.

---

96-96: Added complementary RESOLVED symbol.

Adding the RESOLVED symbol complements the existing NOT_RESOLVED symbol, creating a consistent pattern for assertion messages.

---

131-137: Useful assertion helper for promises.

The resolves assertion helper provides a clean way to assert that promises resolve without rejection, complementing the existing rejects helper for comprehensive promise testing.

---

138-141: Task validation helper improves test readability.

The isTaskSuccessful assertion encapsulates common task success validation logic, making tests more concise and readable while enforcing consistent validation.

---

259-261: Type-safe object keys extraction utility.

The objectKeys function provides a type-safe way to extract keys from objects with string keys, enhancing type safety in testing code.

src/types/shared.ts (5)

1-2: Direct type definition improves maintainability.

Defining RecordAny directly instead of importing it simplifies dependency management and makes the type more accessible.

---

4-10: Useful utility types for refining object properties.

The NonNullKeys and RequiredKeys utility types provide powerful tools for transforming object types in a type-safe way, especially useful for API parameter validation.

---

20-21: String case conversion utility with attribution.

The PascalToCamelCase utility type with attribution to its source is a good practice. This utility will be helpful for converting between naming conventions in APIs.

---

23-27: Recursive type mapping for deep objects.

The DeepStringRecord type provides a robust way to recursively convert all properties in nested objects to strings, which is useful for serialization and display purposes.

---

29-29: Type alias enhances code maintainability.

The SafeOmit type alias provides semantic clarity and future-proofing. While currently a direct alias for Omit, it establishes a pattern that could be extended with additional safety checks if needed.

src/meilisearch.ts (1)

426-441: Add unit-tests for the new experimental-features endpoints

Code-coverage shows 0 % for the freshly added getExperimentalFeatures & updateExperimentalFeatures paths.
A simple happy-path test (mocking the underlying HttpRequests) would keep these endpoints from going stale or accidentally breaking.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 428-431: src/meilisearch.ts#L428-L431
Added lines #L428 - L431 were not covered by tests

src/types/types.ts (2)

15-18: Potential regression – URLSearchParamsRecord can no longer accept Date instances

Date was removed from the union. A lot of user-land code (including our own integration tests for tasks/jobs) relies on passing Date objects directly to be subsequently stringified via URLSearchParams.
Please double-check usages across the repo – if any still expect to pass a Date, they will now fail to compile.

-  string | string[] | number | number[] | boolean | null | undefined
+  | string
+  | string[]
+  | number
+  | number[]
+  | boolean
+  | Date            // keep backward-compat
+  | null
+  | undefined

---

183-185: Breaking change – DocumentsDeletionQuery.filter is now mandatory

filter moved from optional to required. This is logically correct (the endpoint refuses an empty body), but it is a breaking change for TypeScript users that previously called:

index.deleteDocuments({});

If we intend to keep the stricter typing, flag it prominently in the release notes; otherwise make it optional and let runtime validation handle the error.

README.md (5)

202-202: LGTM: Updated search example with new API signature

The search example now correctly uses the object parameter syntax with the q property instead of passing the query string directly, aligning with the PR's API changes.

---

230-233: LGTM: Search parameters example updated correctly

The example now properly demonstrates how to use the new search API with a single parameter object containing both the query and additional search parameters.

---

276-279: LGTM: Filter example updated with new API signature

The filter example correctly uses the new search API pattern with a single parameter object.

---

304-308: LGTM: Placeholder search example updated properly

The placeholder search example now correctly uses the new object parameter syntax while maintaining all the necessary properties.

---

350-350: LGTM: Abortable search example updated correctly

The abortable search example now uses the object parameter style for the query while keeping the request config as the second parameter.

src/types/search-parameters.ts (14)

1-8: LGTM: Proper imports for utility types

The file correctly imports utility types from shared.js and types.js that are used to build the comprehensive type system for search parameters.

---

9-14: LGTM: Well-documented HybridQuery type

The HybridQuery type is properly defined with the necessary properties and includes a reference to the corresponding Rust type in the Meilisearch backend.

---

15-21: LGTM: MatchingStrategy type with proper transformation

The MatchingStrategy type correctly uses PascalToCamelCase to transform the Pascal case enum values from the backend to camel case for JavaScript, ensuring consistent typing while matching the expected API format.

---

22-37: LGTM: FederationOptions type with experimental flag

The FederationOptions type is well-documented with links to the API documentation and backend type. The experimental remote property is properly marked with a comment, and the undocumented queryPosition property includes a private remark.

---

38-51: LGTM: Clear separation of pagination approaches

The code correctly separates the two pagination approaches (offset/limit and page-based) into distinct types, each with proper documentation links to the API reference.

---

52-59: LGTM: Flexible FilterExpression type

The FilterExpression type properly handles the various formats that filters can be expressed in, with appropriate documentation links and private remarks about how it's handled in the backend.

---

61-117: LGTM: Well-structured search query segments

The search query components are logically divided into segments that can be composed together, with comprehensive documentation links for each property. This approach makes the types more maintainable and easier to understand.

---

120-125: LGTM: Elegant type transformation for GET requests

The IntoGet type transformation elegantly handles the differences between POST and GET request formats, particularly for nested hybrid search parameters that need to be flattened for URL parameters.

---

126-154: LGTM: Comprehensive search query type combinations

These types provide a complete set of options for different pagination approaches and request methods, enabling strongly-typed API interactions while preserving flexibility.

---

139-145: LGTM: Well-documented required pagination constraint

The enforcement of required pagination is well-documented with a clear explanation of why this constraint exists, relating it to the backend implementation and response shape guarantee.

---

156-171: LGTM: Search query types with index integration

These types correctly extend the base search query types to include index UID, enabling multi-search functionality while preserving type safety.

---

173-202: LGTM: Well-structured federation types

The federation-related types are well-structured and properly documented, providing a comprehensive type system for multi-search and federated search capabilities.

---

204-214: LGTM: FacetSearchQuery with proper composition

The FacetSearchQuery type correctly composes with the shared facet and search query segment, ensuring consistency across different query types.

---

215-226: LGTM: SimilarQuery with enforced offset and limit

The SimilarQuery type properly composes multiple segments and uses NonNullKeys to enforce the presence of offset and limit properties, ensuring the API works correctly with this query type.